Thoughts on parametrized roles for Moose

Random Logic on 2008-07-15T22:26:36

Moose might allow roles a little bit more freedom on how the are used by allowing parameters to be passed to roles. So the role can use those during initialization to act accordingly.

This will allow to e.g. set a method prefix for a role's methods, or set some defaults, initialize some other stuff...

Here's how it could look like:

use Moose;
with role 'My::Role'; ### no magic here same as: with 'My::Role';
with role 'MooseX::Log::Log4perl' => ':easy'; ### pass a param
with role 'MooseX::Log::Log4perl', prefix => 'mylog_'; ### pass the param hash/pair to a role


For more on that read this post...


Some of this already (kinda) exists ...

Stevan on 2008-07-16T03:29:43

So we already have a mechanism in place whereby extra parameters can be passed into a role during composition, see Recipie 11 for an example of the features that utilize this. Basically anything that is not another string passed after the roles gets turned into params (rjbs++ for Data::OptList which basically does all that work for me). So your examples would basically turn into this:

with 'My::Role'; ### no need to change this

with 'MooseX::Log::Log4perl' => [ ':easy' ]; ### this might not exactly work, but perhaps this ...

with 'MooseX::Log::Log4perl' => { mode => ':easy' }; ### or something similar

with 'MooseX::Log::Log4perl' => { prefix => 'mylog_' }; ### this will just DWIM

No need to add a new keyword/export either (something which I am extremely hesitant to do and should not be taken lightly).

So, while all these args are passed into the role application already, there is no clear way to do anything with them yet. This is the first hurdle for parameterized roles, how and where are these parameters handled? We have the "alias" and "excludes" features in the core, these are borrowed directly from the original Traits paper and are important tools for role disambiguation if your in a pinch, but they are as much as I am willing to shove into the core at this point. What we need is a more general mechanism which can be used to implement your own parameters which can influence role application/composition. And this is where I stop, cause honestly, I am not sure what that is yet.

- Stevan